Skip to content

agent: @U0AJM7X8FBR Supabase - move all ORG API Keys into my personal account: #12

Open
sweetmantech wants to merge 1 commit intomainfrom
agent/-u0ajm7x8fbr-supabase---move-a-1773859903573
Open

agent: @U0AJM7X8FBR Supabase - move all ORG API Keys into my personal account: #12
sweetmantech wants to merge 1 commit intomainfrom
agent/-u0ajm7x8fbr-supabase---move-a-1773859903573

Conversation

@sweetmantech
Copy link
Copy Markdown
Contributor

@sweetmantech sweetmantech commented Mar 18, 2026

Automated PR from coding agent.

Summary by CodeRabbit

  • Chores
    • Optimized API key management system to improve account-level organization and handling.

Deprecating org API keys in favor of personal API keys.
Updates all account_api_keys rows where account points to an
organization (has members in account_organization_ids) to instead
point to personal account fb678396-a68f-4294-ae50-b8cacf9ce77b.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@supabase
Copy link
Copy Markdown

supabase bot commented Mar 18, 2026

Updates to Preview Branch (agent/-u0ajm7x8fbr-supabase---move-a-1773859903573) ↗︎

Deployments Status Updated
Database Wed, 18 Mar 2026 18:53:33 UTC
Services Wed, 18 Mar 2026 18:53:33 UTC
APIs Wed, 18 Mar 2026 18:53:33 UTC

Tasks are run on every commit but only new migration files are pushed.
Close and reopen this PR if you want to apply changes from existing seed or migration files.

Tasks Status Updated
Configurations Wed, 18 Mar 2026 18:53:39 UTC
Migrations Wed, 18 Mar 2026 18:53:41 UTC
Seeding Wed, 18 Mar 2026 18:53:44 UTC
Edge Functions Wed, 18 Mar 2026 18:53:44 UTC

View logs for this Workflow Run ↗︎.
Learn more about Supabase for Git ↗︎.

@coderabbitai
Copy link
Copy Markdown

coderabbitai bot commented Mar 18, 2026

📝 Walkthrough

Walkthrough

A SQL migration script reassigns all organization-based API keys to a designated personal account. The migration updates the account_api_keys table to change the account ownership of keys previously linked to organizations, while preserving non-organization keys and excluding those already associated with the target personal account.

Changes

Cohort / File(s) Summary
Database Migration
supabase/migrations/20260318000000_migrate_org_api_keys_to_personal_account.sql
New migration script that reassigns org-linked API keys to a personal account using UPDATE with conditional WHERE clause matching organization IDs.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🔑 Keys from orgs, they gather round,
A migration script, so safe and sound,
To personal hands they find their way,
Database dance on this fine day! 🐰✨

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title mentions moving ORG API Keys to a personal account, which directly aligns with the SQL migration that reassigns organization-based API keys to a personal account.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch agent/-u0ajm7x8fbr-supabase---move-a-1773859903573
📝 Coding Plan
  • Generate coding plan for human review comments

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🧹 Nitpick comments (1)
supabase/migrations/20260318000000_migrate_org_api_keys_to_personal_account.sql (1)

11-18: Preserve original key ownership for audit and rollback.

This migration overwrites ownership in place and loses old_account provenance. Capture affected rows before update.

🧾 Suggested pattern
+CREATE TABLE IF NOT EXISTS public.account_api_keys_org_migration_backup (
+  key_id uuid PRIMARY KEY,
+  old_account uuid NOT NULL,
+  migrated_to uuid NOT NULL,
+  migrated_at timestamptz NOT NULL DEFAULT now()
+);
+
+INSERT INTO public.account_api_keys_org_migration_backup (key_id, old_account, migrated_to)
+SELECT aak.id, aak.account, 'fb678396-a68f-4294-ae50-b8cacf9ce77b'::uuid
+FROM public.account_api_keys aak
+WHERE aak.account IN (
+  SELECT DISTINCT organization_id
+  FROM public.account_organization_ids
+  WHERE organization_id IS NOT NULL
+)
+AND aak.account <> 'fb678396-a68f-4294-ae50-b8cacf9ce77b'::uuid
+ON CONFLICT (key_id) DO NOTHING;
+
 UPDATE public.account_api_keys
 SET account = 'fb678396-a68f-4294-ae50-b8cacf9ce77b'
 WHERE account IN (
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In
`@supabase/migrations/20260318000000_migrate_org_api_keys_to_personal_account.sql`
around lines 11 - 18, Before performing the in-place UPDATE to account_api_keys,
record the original account ownership so provenance/rollback are possible:
create or use an audit/temp table and INSERT the rows that will be updated
(SELECT id, account AS old_account, organization_id, NOW() AS migrated_at FROM
public.account_api_keys WHERE account IN (SELECT DISTINCT organization_id FROM
public.account_organization_ids WHERE organization_id IS NOT NULL) AND account
!= 'fb678396-a68f-4294-ae50-b8cacf9ce77b') to preserve old_account, then run the
UPDATE; reference the tables/columns account_api_keys.account,
account_api_keys.id and account_organization_ids.organization_id in your
statements so the captured rows exactly match those the UPDATE will change.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@supabase/migrations/20260318000000_migrate_org_api_keys_to_personal_account.sql`:
- Around line 11-18: Add a precondition that the target personal account ID
'fb678396-a68f-4294-ae50-b8cacf9ce77b' exists before running the UPDATE against
public.account_api_keys; check existence in the accounts table (or equivalent
primary account table) and RAISE EXCEPTION (or abort the migration) if it's
missing so the UPDATE won't fail due to FK constraints; reference the target ID
and the tables account_api_keys and account_organization_ids when adding this
check.
- Around line 11-18: This migration updates the account_api_keys table by
setting account = 'fb678396-a68f-4294-ae50-b8cacf9ce77b' for multiple
organization-derived keys (see account_api_keys.account and
account_organization_ids.organization_id); you must verify and fix
application-level authorization to ensure keys don't gain access to other
organizations: review all code paths that authorize by account (e.g., API
handlers, service methods, middleware) and either (a) preserve original
organization ownership in the migration or map each key to a specific personal
account with an explicit tenant linkage, (b) add application checks that enforce
organization-scoped access for keys now consolidated, or (c) implement
RLS/policies on account_api_keys to enforce tenant scoping; update the migration
to include the chosen approach and add unit/integration tests to cover
authorization behavior for account_api_keys after migration.

---

Nitpick comments:
In
`@supabase/migrations/20260318000000_migrate_org_api_keys_to_personal_account.sql`:
- Around line 11-18: Before performing the in-place UPDATE to account_api_keys,
record the original account ownership so provenance/rollback are possible:
create or use an audit/temp table and INSERT the rows that will be updated
(SELECT id, account AS old_account, organization_id, NOW() AS migrated_at FROM
public.account_api_keys WHERE account IN (SELECT DISTINCT organization_id FROM
public.account_organization_ids WHERE organization_id IS NOT NULL) AND account
!= 'fb678396-a68f-4294-ae50-b8cacf9ce77b') to preserve old_account, then run the
UPDATE; reference the tables/columns account_api_keys.account,
account_api_keys.id and account_organization_ids.organization_id in your
statements so the captured rows exactly match those the UPDATE will change.

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: cb99a6a5-460e-4555-b829-9760654b219e

📥 Commits

Reviewing files that changed from the base of the PR and between a1726b8 and 9aa80c1.

📒 Files selected for processing (1)
  • supabase/migrations/20260318000000_migrate_org_api_keys_to_personal_account.sql

Comment on lines +11 to +18
UPDATE public.account_api_keys
SET account = 'fb678396-a68f-4294-ae50-b8cacf9ce77b'
WHERE account IN (
SELECT DISTINCT organization_id
FROM public.account_organization_ids
WHERE organization_id IS NOT NULL
)
AND account != 'fb678396-a68f-4294-ae50-b8cacf9ce77b';
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Add a precondition check that the target personal account exists.

If fb678396-a68f-4294-ae50-b8cacf9ce77b is missing in any environment, this update can fail on FK enforcement and block the migration.

🔧 Proposed fix
+DO $$
+BEGIN
+  IF NOT EXISTS (
+    SELECT 1
+    FROM public.accounts
+    WHERE id = 'fb678396-a68f-4294-ae50-b8cacf9ce77b'::uuid
+  ) THEN
+    RAISE EXCEPTION
+      'Target personal account % does not exist',
+      'fb678396-a68f-4294-ae50-b8cacf9ce77b';
+  END IF;
+END $$;
+
 UPDATE public.account_api_keys
 SET account = 'fb678396-a68f-4294-ae50-b8cacf9ce77b'
 WHERE account IN (
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
UPDATE public.account_api_keys
SET account = 'fb678396-a68f-4294-ae50-b8cacf9ce77b'
WHERE account IN (
SELECT DISTINCT organization_id
FROM public.account_organization_ids
WHERE organization_id IS NOT NULL
)
AND account != 'fb678396-a68f-4294-ae50-b8cacf9ce77b';
DO $$
BEGIN
IF NOT EXISTS (
SELECT 1
FROM public.accounts
WHERE id = 'fb678396-a68f-4294-ae50-b8cacf9ce77b'::uuid
) THEN
RAISE EXCEPTION
'Target personal account % does not exist',
'fb678396-a68f-4294-ae50-b8cacf9ce77b';
END IF;
END $$;
UPDATE public.account_api_keys
SET account = 'fb678396-a68f-4294-ae50-b8cacf9ce77b'
WHERE account IN (
SELECT DISTINCT organization_id
FROM public.account_organization_ids
WHERE organization_id IS NOT NULL
)
AND account != 'fb678396-a68f-4294-ae50-b8cacf9ce77b';
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In
`@supabase/migrations/20260318000000_migrate_org_api_keys_to_personal_account.sql`
around lines 11 - 18, Add a precondition that the target personal account ID
'fb678396-a68f-4294-ae50-b8cacf9ce77b' exists before running the UPDATE against
public.account_api_keys; check existence in the accounts table (or equivalent
primary account table) and RAISE EXCEPTION (or abort the migration) if it's
missing so the UPDATE won't fail due to FK constraints; reference the target ID
and the tables account_api_keys and account_organization_ids when adding this
check.

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

# Find SQL objects referencing account_api_keys
rg -n -C3 --type=sql '\baccount_api_keys\b'

# Find account-scoping logic tied to account_api_keys.account
rg -n -C4 --type=sql 'account_api_keys\.account|USING\s*\(|WITH\s+CHECK\s*\(|\baccount\s*='

Repository: recoupable/database

Length of output: 6245


🏁 Script executed:

rg -n "CREATE POLICY.*account_api_keys|ON.*account_api_keys" --type=sql

Repository: recoupable/database

Length of output: 725


🏁 Script executed:

rg -n "CREATE POLICY" --type=sql -A 3 | head -100

Repository: recoupable/database

Length of output: 1316


🏁 Script executed:

cat -n supabase/migrations/20251206000000_create_account_api_keys.sql

Repository: recoupable/database

Length of output: 1222


🏁 Script executed:

find supabase/migrations -name "*.sql" -type f | xargs grep -l "account_api_keys\|account.*policy" | xargs cat | grep -n "CREATE POLICY\|account_api_keys" | head -50

Repository: recoupable/database

Length of output: 646


🏁 Script executed:

cat -n supabase/migrations/20260318000000_migrate_org_api_keys_to_personal_account.sql

Repository: recoupable/database

Length of output: 964


🏁 Script executed:

rg -n "account_api_keys" --type=sql -A 5 -B 2 | grep -E "FUNCTION|CREATE|SELECT|WHERE" | head -50

Repository: recoupable/database

Length of output: 934


🏁 Script executed:

rg "account_api_keys.*POLICY|POLICY.*account_api_keys" --type=sql

Repository: recoupable/database

Length of output: 45


🏁 Script executed:

find supabase/migrations -name "*.sql" -type f -exec grep -l "POLICY" {} \; | xargs basename -a

Repository: recoupable/database

Length of output: 115


Verify whether reassigning all org keys to one account breaks application logic.

No RLS policies are defined for account_api_keys, so authorization is not scoped via the account column at the database level. However, the migration still consolidates keys from multiple organization accounts into a single personal account (fb678396-a68f-4294-ae50-b8cacf9ce77b). Confirm that application-level authorization correctly handles this consolidation and that keys don't gain unintended access to other organizations.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In
`@supabase/migrations/20260318000000_migrate_org_api_keys_to_personal_account.sql`
around lines 11 - 18, This migration updates the account_api_keys table by
setting account = 'fb678396-a68f-4294-ae50-b8cacf9ce77b' for multiple
organization-derived keys (see account_api_keys.account and
account_organization_ids.organization_id); you must verify and fix
application-level authorization to ensure keys don't gain access to other
organizations: review all code paths that authorize by account (e.g., API
handlers, service methods, middleware) and either (a) preserve original
organization ownership in the migration or map each key to a specific personal
account with an explicit tenant linkage, (b) add application checks that enforce
organization-scoped access for keys now consolidated, or (c) implement
RLS/policies on account_api_keys to enforce tenant scoping; update the migration
to include the chosen approach and add unit/integration tests to cover
authorization behavior for account_api_keys after migration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant